A network generally includes a number of devices connected to allow inter-device communication. To monitor the status of any given device on a network, a network management station transmits a message requesting information over the network to an agent running on the given device. In response, the agent sends a message including the requested information over the network to the network management station. The network management station communicates with agents according to a protocol, such as the Simple Network Management Protocol (SNMP).
However, before the network management station can request status information from an agent, the network management station must know the type of information that a given agent is able to provide. Different agents are capable of providing different types of information. To better monitor, debug, and optimize a network, the network management station should be able request all of the information any given agent on the network is capable of supplying.
The type of information a given agent can provide depends on the Management Information Bases (MIBs) it supports. A MIB specifies groups of objects, and each object defines a group of data types. An agent supports a MIB if the agent is capable of supplying the type of information defined in the objects specified in the MIB. Most agents can provide the type information defined in the objects specified in certain standard MIBs, known as MIB I and MIB II. However, even support for these standard MIBs varies from agent to agent. In addition, each agent may support a different version of a MIB, or support proprietary MIBs. Finally, many agents have more than one mode. An agent executing in one mode may support different MIBs than the same agent executing in another mode.
Consequently, for the network management station to have access to all of the information a device can provide, the network management station must first identify the agent running on the device. Once the identity of the agent is known, the network management station can access a MIB database to determine which MIBs the identified agent supports. Once the MIBs supported by the agent at issue have been determined, the network management station can request from the agent the information defined in the objects specified in the supported MIBs.
In light of the foregoing, it is clearly desirable to provide an apparatus and method for identifying an agent running on a device in a network system. Further, it is clearly desirable to determine the MIBs supported by the agent in order for the network management station to access all of the information the agent is able to provide. Finally, it is clearly desirable to provide an agent identifying apparatus and method that is fast and efficient.
Different agents respond to the queries in different ways. Therefore, one way to determine the identity of a given agent is to send the given agent certain selected queries and then compare responses of the given agent to the responses that would be expected from a first selected type of agent. If the actual responses match the expected responses, then the given agent is determined to be the first selected type of agent. If the actual responses do not match the expected responses, then the given agent is determined not be the first selected type of agent.
If the actual agent is not the first selected type of agent, then a second set of selected queries are sent to the agent, and the responses to the second set of selected queries are compared to the responses that would be expected from a second selected type of agent. If the actual responses match the expected responses, then the given agent is the second selected type of agent. If the actual responses do not match the expected responses, then this agent by agent response comparison process is repeated until the given agent is positively identified.
One obvious problem with the agent by agent identification process described above is that it is slow and inefficient. On average, this identification process requires x/2 query-response-comparison operations, where x is the number of known agents. The performance of these operations may result in unacceptable delays. For every two new agents developed, the number of query-response-comparison operations required to identify an average agent increases by one. Further, each query and each response is sent over the network. Therefore, the greater the number of query-response-comparison operations required for each identification process, the greater the amount of network traffic generated by the identification process.
A second problem with the agent-by-agent identification process is that a given implementation of the agent-by-agent identification method will not identify agents and agent versions which are developed after the given implementation. Specifically, responses from a newly developed agent will typically not match the responses expected from any previously known agent. Therefore, an attempt to match the responses from a new agent to responses expected from each of the previously known agents will fail. Further, the identification failure only occurs after time and network resources have been expended in performing a query-response-comparison operation for each previously known agent. Once an attempt to identify a newly developed agent has failed, the network management system may return an error message, or may request information from the unidentified agent under an assumption that the new agent supports a standard MIB (MIB I or MIB II).
In light of the foregoing, an agent identification mechanism that is easily updated to identify newly developed agents is desirable. Further, an agent identification mechanism whose efficiency is not substantially affected by the addition of support for new agents is clearly desirable. Finally, an agent identification mechanism which, upon encountering a new, unsupported agent, is able to identify a known agent with similar capabilities to the unsupported agent, is clearly desirable.